Practical Congestion Control for Multipath Transport Protocols

Multipath transport protocols have the potential to greatly improve the performance and resilience of Internet traffic flows. The basic idea is that if flows are able to simultaneously use more than one path through the network, then they will be more resilient to problems on particular paths (e.g. transient problems on a radio interface), and they will be able to pool capacity across multiple links. These multiple paths might be obtained for example by sending from multiple interfaces, or sending to different IP addresses of the same host, or by some form of explicit path control. Multipath-capable flows should be designed so that they shift their traffic from congested paths to uncongested paths, so that the Internet will be better able to accommodate localized surges in traffic and use all available capacity. In effect, multipath congestion control means that the end systems take on a role that is normally associated with routing, namely moving traffic onto paths that avoid congestion hotspots, at least to whatever extent they can given the paths they have available. When a flow shifts its traffic onto less congested paths, then the loss rate on the less congested path will increase and that on the more congested path will decrease; the overall outcome with many multipath flows is that the loss rates across an interconnected network of paths will tend to equalize. This is a form of load balancing, or more generally resource pooling [14], described further in §2. Multipath congestion control should be designed to achieve a fair allocation of resources. For example, if a multipath flow has four paths available and they all happen to go through the same bottleneck link, and if we simply run TCP’s congestion avoidance independently on each path, then this flow will grab four times as much bandwidth as it should. In fact, the very idea of “shifting traffic from one path to another” in the previous paragraph presupposes that there is some fair total traffic rate, and that extra traffic on one path should be compensated for by less traffic on the other. The problem of fairness is made even harder by round-trip-time dependence. For example, in figure 1, suppose that path A1 has a loss rate of 4% and a round trip time of 10ms, and path A2 has a loss rate of 1% and a round trip time of 100ms. Resource pooling suggests that flow A should send all its traffic on the less congested path A2, but a simple-minded interpretation of TCP fairness says that A